As the performance and complexity of computers and other electronic devices, and of the underlying electronic components utilized thereby, continues to increase, the processes of developing, testing and debugging particular hardware and/or software designs has likewise become increasingly more complex and cumbersome. Moreover, as computers and electronic devices have become more ubiquitous in many aspects of everyday life, the demand for such devices has likewise increased, as has the demand for automated tools for assisting in the development of such devices in a quicker and more cost effective manner. Shortening product life cycles, as well as market demands, have likewise necessitated shortened development cycles, which has further increased the demand for automated tools to accelerate product development.
As an example, developing software for digital signal processors (DSP's) has become increasingly important. DSP's are specialized computer chips similar in many respects to computer microprocessors; however, they are typically tailored for incorporation into products and processes, rather than general purpose computers, to make those products and processes “smart”. In many instances, DSP's are geared toward real-time, low cost and/or low power consumption applications where general purpose microprocessors would not be economically or technologically viable.
DSP's are proliferating in every facet of the consumer and industrial markets, and have become the hardware engines powering the Internet, as well as many communications, wireless and entertainment products. DSP's are now used in a large percentage of consumer electronics, hearing aids, toys, appliances, cell phones, television set top boxes, automobiles and industrial applications.
DSP's typically implement advanced signal processing algorithms that perform detailed mathematical analysis and/or manipulation of input data representative of real world information. The input data is typically presented to a DSP in digital form, resulting in the generation of digital output data. The real world, however, is often analog, and not digital, in nature. As a result, some conversion between the digital domain and another domain is often required.
For example, in a digital audio system, a DSP may be used to add a reverb effect to a sound signal received from a microphone or other audio source, which is then amplified and played back over a speaker. The sound signals received by a microphone and later played back over a speaker, however, are in the form of time-varying waves of energy. A microphone typically generates a time-varying analog voltage signal in response to a sound wave, and a speaker likewise is driven by a time-varying analog voltage signal.
To enable a DSP to apply a digital reverb effect, therefore, analog-to-digital conversion is required to convert the analog voltage signal from a microphone to a digital format suitable for the DSP, and digital-to-analog conversion is required to convert the digital output of the DSP to an analog format suitable for driving a speaker. For analog-to-digital conversion, an analog signal is sampled at predetermined intervals, e.g., 1/40,000 of a second, resulting in the generation of a stream of numbers. Likewise, for digital-to-analog conversion, a stream of numbers is typically used to drive an analog voltage signal. However, given that only a finite number of digits can be used to digitally represent an analog value, digital values are inherently approximations of analog values. Both A/D and D/A operations are thus limited by the quality of the A/D and D/A conversion circuitry, and as a result, some inaccuracy and/or imprecision always results from the use of DSP's in an analog environment.
Often of equal or greater significance are the inaccuracies that result from conducting mathematical computations in DSP's with operand numbers that are represented with limited precision. In particular, to reduce cost and power consumption, many DSP's forego the use of floating point numbers for fixed point numbers with a limited number of bits of precision, e.g., 16, 24 or 32 bits. The rounding errors that typically result when conducting mathematical operations on limited precision numbers can be significant, even to the point of causing certain mathematical operations such as digital filters to become unstable. As a result, in some instances, a signal processing operation that produces a desirable result when simulated in a general purpose computer with comparably high precision may have unacceptably high levels of numerical noise, or may even be totally unstable, when implemented in a DSP with limited precision.
One problem facing many designers of DSP-based products is therefore ensuring that a DSP algorithm remains stable and achieves a desired result in real-world applications.
Like a general purpose computer, a DSP requires software to tailor the DSP to perform particular functions, or to implement particular mathematical algorithms. However, creating DSP software is often more difficult than creating software for a general purpose computer for a number of reasons. DSP's are typically designed to be low power and inexpensive, which can limit the memory, processing power and numerical precision available in a DSP design. In addition, many DSP applications require real-time processing, where operations are required to be performed within explicit and demanding time constraints. In some consumer audio applications, for instance, a DSP must execute its complete program cycle 48,000 times per second in order to suitably process an audio stream. These heightened requirements drive the complexity of DSP design, and consequently compound the difficulty of programming suitable software for use in a particular DSP application.
Coupled with the growth in DSP use, there has been a trend towards increasing complexity in chip designs, which also makes programming DSP software more difficult. As a result, software development has been found to be a major factor—if not the major factor—determining the time-to-market and product cost of a DSP-based design.
One fundamental difficulty associated with DSP software design is due to the fact that, in many instances, the skill sets of the individuals that are attempting to integrate DSP-based functionality into a product can be widely divergent. On the one hand, it is often the application experts on a product design team who are tasked with developing the desired algorithms to implement on a DSP, as these experts are generally skilled in the fundamental technologies for the product. On the other hand, the actual implementation of these algorithms in suitable software is often the domain of a software engineer who is better versed in software development and the capabilities of the underlying DSP hardware, but who may not be particularly well versed in those fundamental technologies. For example, in the development of a product such as the aforementioned digital audio system, an application expert for such a product would likely be well versed in sound theory and filtering algorithms, but might not be skilled in computer programming, while a DSP programmer for such a product would not necessarily have a specific expertise in sound theory or the related mathematics.
Certainly, when the individual that codes DSP software does not have a fundamental understanding of the underlying technology within which it will be used, inefficiencies arise due to the need for the involvement of an application expert in the development process. Like all software, DSP software must often be tested, debugged, and reworked before the final software is acceptable for its intended application, and in many instances, application-specific expertise is required in all of these steps. As a result, DSP software design can be burdensome, time consuming and expensive.
To address many of these inefficiencies, substantial efforts have been directed toward simplifying the design, testing and debugging of DSP software, typically through the use of software tools that automate many of the aspects of these processes. For example, as with other types of software, DSP software development has been aided by the use of graphical development environments, where graphical constructs are used to represent the various components of a DSP software program. Often, such environments permit DSP algorithms to be represented in block diagram format, with manipulation of the graphical constructs by the developer resulting in modifications to the underlying software. In addition, libraries of preexisting components may be supported, such that a developer is able to construct an algorithm predominantly by assembling together multiple preexisting components. Such a graphical user interface environment may be used in development, simulation, analysis, testing and debugging of DSP software, often resulting in substantially greater efficiency and reduced development cycles.
Moreover, the inherent intuitiveness of a graphical development environment often reduces learning curves and the required expertise in software programming. In fact, as the sophistication of automated development tools has increased, application experts have begun to assume at least some of the tasks traditionally performed by software engineers in connection with DSP-based product design.
To the extent that the tasks involved with DSP-based product design can be consolidated within a narrower skill set, faster, less expensive and more efficient development often results. In addition, given the application-specific knowledge that is nearly always required when implementing DSP technology in any product, empowerment of application experts to subsume the tasks traditionally relegated to software engineers is often highly desirable. Accordingly, a continuing need exists for automated development tools that simplify the various processes involved with developing DSP software.
As one example, designing any new device or product (DSP-based or otherwise) typically involves converting a specification or other form of “reference” system into a physical device or other implementation that satisfies the specification. The specification can be in many different forms, anything from a causal verbal description to a detailed executable computer simulation of the desired behavior. Regardless, problems arise whenever an implementation of a specification, hereinafter referred to as a “target design”, does not behave as expected or desired, i.e., when the implementation departs from the specification. Identifying the source of a problem, and then remedying the problem, however, may prove difficult, particularly for complex products such as DSP-enabled products and the like.
For DSP-based products, one potential source of problems arises due to the inherent limitations of digitally representing real world information. A digital representation of an analog value is limited by the precision of the digital representation. For example, the value of Tr can be represented using differing degrees of precision, e.g., 3.142857, 3.14, 3, etc., based upon the number of digits used to represent the value. Moreover, converting an analog value to digital requires some degree of rounding to arrive at the desired precision, and as a result, at least some inaccuracy or error will always be introduced whenever an analog value is represented in digital form.
Even more significant errors can occur when conducting mathematical operations on limited precision numbers. For example, when the difference is taken between large numbers of similar value, the rounding error may be as large or larger than the correct result. Moreover, for recursive operations such as infinite impulse response filters, which are often implemented in DSP's, these rounding errors are often fed back as inputs to subsequent computations. In such instances, the errors can be amplified greatly, potentially causing the results of a mathematical operation to become unbounded and the operation to be unstable.
While in many instances, the introduced error will have negligible effect on a DSP algorithm, in other instances, e.g., where a high degree of precision and dynamic range are required, the errors can propagate through an algorithm and introduce incorrect and/or unpredictable results.
Furthermore, whenever a specification is created for a DSP-based product, often the precision used when creating the specification is greater than that which is economically and/or technologically feasible in an implementation of the specification. Thus, problems may arise in the implementation due to numerical imprecision in the implementation.
Other problems can arise due to unexpected, undocumented or undiscovered aspects of the behavior of DSP hardware, associated compilers and/or low level DSP instructions. For example, it has been found that certain DSP designs exhibit unexpected errors in the way numbers are rounded. Such designs, for example, may round computation results up to a next highest numerical representation, despite the fact that the behavior specified by the manufacturers of those designs specify that results are rounded to a nearest numerical representation.
Locating and resolving the sources of these types of problems, however, can be difficult, particularly for complex algorithms. Even when algorithms are represented by block diagrams, as used by graphical development environments, such algorithms may be represented by hundreds or thousands of blocks, each of which could be the potential source of a problem.
Conventionally, locating problems in DSP software, even via a graphical development environment, can be cumbersome, requiring sampling of individual signals and comparison of such sampled signals to expected values. Once an incorrect signal is located, a determination is then required to be made as to whether the signal is indicative of the root cause of the problem, or if it is just an artifact of a problem earlier in the signal flow, typically by iteratively backtracking through a block diagram, checking earlier signals in the signal flow, and looking for other problems. Such a process that can be extremely tedious and time consuming, particularly if a signal flow passes through hundreds of blocks. Moreover, in some instances, a feedback loop may be present in a signal flow, which may prevent identification of a root source of a problem simply through backtracking through the signal flow. Typically, these situations require more complex search strategies, most of which rely on breaking a loop and looking at specific subsets of signals in the loop.
As such, a significant need has arisen in the art for a manner of simplifying the process of debugging DSP software, and in particular DSP software developed, tested and debugged in a graphical development environment.